1. Field of Art
The present invention relates generally to the field of virtualization, and more particularly to virtualization of mobile apps running on distant computing platforms.
2. Description of Related Art
As computing systems have evolved, so too has the need to mimic the functionality of computer hardware, operating systems, applications and other computing resources. For example, computer simulations of natural systems (travel in outer space, city traffic patterns, etc) are often employed to model and predict the behavior of such systems under varying conditions. Computer emulators have been developed to avoid the obsolescence of older computer platforms by duplicating their functionality on a modern platform (e.g., emulating an Atari game system on a general-purpose personal computer to enable users to continue to play games written for the older platform). Hardware and software components of computer systems under development can also be emulated to assess their behavior in a system environment. Moreover, “virtual machines” have been developed to mimic the behavior of a “guest” platform (e.g., the Microsoft Windows operating system and applications, as well as hardware peripherals) on a “host” platform (e.g., Macintosh computer).
Though terms such as “simulation,” “emulation” and “virtualization” are often used inconsistently and in various different contexts, the need to mimic the functionality of particular computing resources remains a constant thread. For the purposes of this specification, these terms can be considered interchangeable in this context.
Moreover, the physical form in which such functionality is implemented can vary from dedicated computer hardware to software running on a general-purpose computer to a myriad of hybrid implementations allocating such functionality among hardware and software components. It should be noted that even software components are typically embodied in physical non-transitory storage media (i.e., memory), such as hard disk drives, flash memory, etc.
One form of virtualization, sometimes referred to as “remote” virtualization, involves the interaction of two computing environments—a host server environment in which the actual computing resources to be virtualized reside, and a remote guest/client device environment from which these resources are controlled. In this context, one can say that the “virtual” resources reside on the client device, while the actual resources reside in the host environment (though the host might also include additional virtual resources, such as virtual machines).
Remote desktop virtualization software (PC Anywhere, VNC software, etc) enables users to remotely control applications (running, e.g., on their desktop computers) from a client device at a remote location (e.g., a smartphone or laptop in a hotel room). Such software enables a user from a remote location to input events (e.g., keystrokes and touch events) into a smartphone, and see the results of such interactions (e.g., screen displays) on the smartphone, while the applications being controlled might actually reside and execute on a host computer at the user's home or business. Other “cloud-based” remote virtualization systems (OnLive, CloudOn, GaiKai, etc) offer similar functionality to remotely control particular applications, such as office suites and games designed to run on desktop computers, gaming platforms, etc.
Thus, remote virtualization enables users to access, from a remote location, computing resources that, for a variety of reasons, are not otherwise available at the remote location. With the advent of smartphones and mobile “apps” (e.g., applications designed for mobile devices), users now have the ability to take their mobile apps with them to essentially any location. Why then would a smartphone user need a “virtual mobile app?”
There are a number of answers to that question, which explain the relatively recent influx of purported solutions to the “virtual mobile app” problem. One aspect of this problem is the existence of multiple mobile platforms (iPhone, Android, etc), and the lack of availability of certain mobile apps on particular mobile platforms (e.g., an iPhone app that is not available on Android smartphones). Another problem is the obstacle of downloading and installing a mobile app, which might appear to be a minor inconvenience on the surface, but which has been shown to be a significant hurdle in practice. For example, a user desiring to try a calculator app might want to demo 5 different apps for a few minutes each before selecting the most desired one. But, some apps may not offer free “trial” versions, while other apps may require more time to download and install than to demo.
Thus, there exists a need for a “virtual mobile app” that can be invoked from a user's smartphone, and provide the user experience of a native mobile app, but without ever requiring that the mobile app be downloaded and installed on the user's smartphone. A few companies (e.g., Piecable, acquired by Facebook, and Kickfolio) have recently attempted to address this problem by enabling smartphone users to demo mobile apps via their mobile web browser (with Piecable using Flash and Kickfolio using HTML5). Other companies, such as Agawi (e.g., Agawi's AppGlimpse mobile advertising platform and US Pat. App. No. 2013/0013671), have sought to move into the virtual mobile app space by enabling users to demo virtual mobile apps as “advertisements” invoked from a native mobile app.
What these existing “solutions” fail to address, however, is the need to mimic the complete user experience, as if the user was running a native mobile app instead of a virtual mobile app. Merely capturing user input events and displaying resulting screen displays is insufficient. For example, mobile apps may also have a need to access certain local resources available only in the native environment of the user's smartphone, and not on a distant host server. Such resources might include, among others, a smartphone's local data store (e.g., data shared among mobile apps or available to the mobile app currently being executed), its current location (as determined via local GPS hardware on the smartphone) and its surrounding environment (as captured by a camera on the smartphone).
While the Agawi patent application referenced above briefly alludes to this problem, it does not provide or suggest a workable solution that would resolve this problem:    “To achieve a seamless user experience, the data specific to mobile devices 124 are also captured in the mobile device and sent through the control channel to the control server 220. This data may include the device orientation, GPS location, gyro/accelerometer data, and the like.”[US Pat App No 2013/0013671, last 2 sentences of Paragraph 0072].
For example, if a virtual mobile app simply captured GPS data and passed it to the control server 220, how would that data be passed to the “native” mobile app running on the server? Moreover, it would be terribly inefficient to capture GPS data without any knowledge of when/whether the mobile app required that data. One of the cited examples, device orientation, could be passed to the control server 220 in the same manner as other “local input events,” because mobile devices typically include a mechanism for “pushing” all such events to mobile apps.
But, the other cited examples (GPS location and gyro/accelerometer data), and many others not mentioned in Agawi (such as local data, cameras, microphones, speakers, network devices, etc) do not fall into the category of “user-initiated” events that are automatically “pushed” to mobile apps without the necessity of a runtime request (even if a mobile app can opt out or ignore such events). Instead, such “app-initiated” events are defined at runtime at the request of the mobile app itself. For example, a mobile app might, at a certain point during its execution, request that the smartphone's camera take a picture, that its GPS hardware notify the mobile app when the smartphone's location changes by a certain threshold, or that it initiate a network request via the smartphone's WiFi or Bluetooth hardware.
Examples of user-initiated events include keystrokes (from a physical keyboard or “soft” keypresses on a touchscreen), touch events and device orientation. While a mobile app is running, the mobile OS (operating system) in a mobile device automatically notifies the mobile app when such user-initiated events occur. The native code of the mobile app typically includes “handlers” to respond to such events.
Mobile devices do not, however, automatically notify mobile apps whenever the device's location changes (as detected by its GPS or gyro/accelerometor hardware), or whenever sound is detected by the device's microphone or an image is detected by one of the device's cameras. Such a mechanism (alluded to by Agawi above) would be terribly inefficient and would significantly drain the device's battery.
Instead, a mobile app must define such app-initiated events by making an explicit runtime request (typically to the mobile OS) for the device to detect a particular change in location, to capture sound or take a picture. In response to such runtime requests, the mobile OS then notifies the mobile app when the app-initiated event has occurred, providing a mechanism to retrieve any resulting data (location coordinates, sound samples, images, etc.). Though a mobile app would still include a “handler” to respond to such app-initiated events, it is important to distinguish these app-initiated events (that are defined by runtime requests from a mobile app) from user-initiated events (that are automatically provided to a mobile app).
In the context of a virtual mobile app, app-initiated events that require local client resources must be handled very differently from user-initiated events, because a mobile app running on a distant host server does not have direct access to a mobile device's local resources (local data store, GPS chip, accelerometer, cameras, microphones, speakers, WiFi and Bluetooth network devices, etc).
Unlike a mobile operating system that can be simulated on a host server and accessed by a mobile app, a mobile device's local resources cannot be simulated on a distant host server in the same manner. For example, if a mobile app running on a distant host server requests that the mobile device take a picture with its camera, how would the simulated mobile operating system on the host server successfully complete that request when it does not have access to that camera?
What is needed is a mobile app remote virtualization system and process that addresses this problem in a manner that is transparent to the mobile app, which “thinks” it is running on a client mobile device. Any solution must successfully handle (in addition to user-initiated events) app-initiated events (also referred to herein as application-initiated events) triggered by the mobile app running in a host server environment by somehow coordinating with the client mobile device which has access to the requested local resources.